1. Field of the Invention
The present invention generally relates to managing interdependent data objects and, more particularly, to managing modifications to at least one of a plurality of interdependent data objects.
2. Description of the Related Art
Databases are computerized information storage and retrieval systems. The most prevalent type of database is the relational database, a tabular database in which data is defined so that it can be reorganized and accessed in a number of different ways. A distributed database is one that can be dispersed or replicated among different points in a network. An object-oriented programming database is one that is congruent with the data defined in object classes and subclasses.
Regardless of the particular architecture, a database management system (DBMS) can be structured to support a variety of different types of operations for a requesting entity (e.g., an application, the operating system or an end user). Such operations can be configured to retrieve, add, modify and delete information being stored and managed by the DBMS. Standard database access methods support these operations using high-level query languages, such as the Structured Query Language (SQL). The term “query” denominates a set of commands that cause execution of operations for processing data from a stored database. For instance, SQL supports four types of query operations, i.e., SELECT, INSERT, UPDATE and DELETE. A SELECT operation retrieves data from a database, an INSERT operation adds new data to a database, an UPDATE operation modifies data in a database and a DELETE operation removes data from a database.
Unfortunately, generating queries using SQL (and other query languages) may require a detailed understanding of the possibly complex physical layout of the underlying database and interpretation of cryptic field names. For some applications, to facilitate the query building process, an abstraction model may be utilized that, in effect, hides some of the complexities of the physical layout of the underlying database from users. The abstraction model may include logical fields with recognizable names that map to corresponding physical fields of the underlying database. “Abstract” queries may be generated containing conditions based on the logical fields. Upon issuance, the logical fields of an abstract query may be mapped to corresponding physical fields to create a physical or “concrete” query. For some applications, abstract queries may be saved, allowing subsequent users to reuse the saved abstract queries without having to generate their own. The concepts of data abstraction and abstract queries are described in detail in the commonly owned, co-pending application Ser. No. 10/083,075, entitled “APPLICATION PORTABILITY AND EXTENSIBILITY THROUGH DATABASE SCHEMA AND QUERY ABSTRACTION”, filed Feb. 26, 2002, issued as U.S. Pat. No. 6,996,558B2, on Feb. 7, 2007, herein incorporated by reference in its entirety.
Abstract queries often contain a conditional element (e.g., a WHERE clause in a corresponding SQL statement) in which a logical field is used within an expression with a comparison operator. As described in the related application Ser. No. 10/083,075, logical fields are typically mapped to a particular physical field in a physical database. For instance, if the physical database was implemented as a relational database, a particular logical field would be mapped to a particular column within a relational table.
Using a data abstraction model according to the framework of the '075 application, abstract queries can be constructed based on the framework without regard for the makeup of the underlying physical data. For instance, assume a user in a hospital who wants to determine last and first names of patients having had a Hemoglobin test (HgBA1c) with a corresponding result value greater than 10%. To this end, the user may specify the following abstract query:                FIND LAST NAME, FIRST NAME        WHERE HGBA1C-RESULT >10where “LAST NAME”, “FIRST NAME” and “HGBA1C-RESULT” are logical field names of respective logical fields defined by the data abstraction model. While the logical fields map to physical fields, the user constructs abstract queries on the basis of the data abstraction model, without requiring any knowledge of the physical data.        
In a framework such as the one of the '075 application, data objects used in a given environment can be stored persistently. For instance, in the above example, the data abstraction model defining at least the logical fields “LAST NAME”, “FIRST NAME” and “HGBA1C-RESULT” and the abstract query which uses these logical fields can be stored persistently. One issue that arises where objects are stored persistently is the effect of changes to the framework environment in which users operate. For instance, the given user may modify or delete a logical field of the data abstraction model or redefine a query condition of the abstract query. However, such changes may affect one or more of the persistently stored objects. For instance, assume that in the given example a user deletes the logical field “HGBA1C-RESULT” from the data abstraction model. As the exemplary abstract query (shown above) uses this logical field as a condition field, the abstract query can no longer be loaded and executed and, thus, becomes invalid.
Therefore, there is a need for an efficient technique for tracking and coordinating modifications to interdependent objects.